Unveiling SSHCure 3.0: Flow-based SSH Compromise Detection

Network-based intrusion detection systems have always been designed to report on the presence of attacks. Due to the sheer and ever-increasing number of attacks on the Internet, Computer Security Incident Response Teams (CSIRTs) are overwhelmed with attack reports. For that reason, there is a need for the detection of compromises rather than compromise attempts, since those incidents are the ones that have to be taken care of. In previous works, we have demonstrated and validated our state-of-the-art compromise detection algorithm that works on exported flow data, i.e, data exported using NetFlow or IPFIX. The detection algorithm has been implemented as part of our open-source intrusion detection system SSHCure.\ud In this demonstration, we showcase the latest release of SSHCure, which includes many new features, such as an overhauled user interface design based on user surveys, integration with incident reporting tools, blacklist integration and IPv6 support. Attendees will be able to explore SSHCure in a semi-live fashion by means of practical examples of situations that CSIRT members encounter in their daily activities

Attacks by “Anonymous” WikiLeaks Proponents not Anonymous

On November 28, 2010, the world started watching the whistle blower website WikiLeaks to begin publishing part of the 250,000 US Embassy Diplomatic cables. These confidential cables provide an insight on U.S. international affairs from 274 different embassies, covering topics such as analysis of host countries and leaders and even requests for spying out United Nations leaders.\ud The release of these cables has caused reactions not only in the real world, but also on the Internet. In fact, a cyberwar started just before the initial release. Wikileaks has reported that their servers were experiencing distributed denial-of-service attacks (DDoS). A DDoS attack consists of many computers trying to overload a server by firing a high number of requests, leading ultimately to service disruption. In this case, the goal was to avoid the release of the embassy cables.\ud After the initial cable release, several companies started severed ties with WikiLeaks. One of the first was Amazon.com, that removed the WikiLeaks web- site from their servers. Next, EveryDNS, a company in which the domain wikileaks.org was registered, dropped the domain entries from its servers. On December 4th, PayPal cancelled the account that WikiLeaks was using to receive on-line donations. On the 6th, Swiss bank PostFinance froze the WikiLeaks assets and Mastercard stopped receiving payments to the WikiLeaks account. Visa followed Mastercard on December 7th.\ud These reactions caused a group of Internet activists (or “hacktivists”) named Anonymous to start a retaliation against PostFinance, PayPay, MasterCard, Visa, Moneybrookers.com and Amazon.com, named “Operation Payback”. The retaliation was performed as DDoS attacks to the websites of those companies, disrupting their activities (except for the case of Amazon.com) for different periods of time.\ud The Anonymous group consists of volunteers that use a stress testing tool to perform the attacks. This tool, named LOIC (Low Orbit Ion Cannon), can be found both as a desktop application and as a Web page.\ud Even though the group behind the attacks claims to be anonymous, the tools they provide do not offer any security services, such as anonymization. As a consequence, a hacktivist that volunteers to take part in such attacks, can be traced back easily. This is the case for both current versions of the LOIC tool. Therefore, the goal of this report is to present an analysis of privacy issues in the context of these attacks, and raise awareness on the risks of taking part in them

Unveiling flat traffic on the internet: An SSH attack case study

Many types of brute-force attacks are known to exhibit a characteristic ‘flat’ behavior at the network-level, meaning that connections belonging to an attack feature a similar number of packets and bytes, and duration. Flat traffic usually results from repeating similar application-layer actions, such as login attempts in a brute-force attack. For typical attacks, hundreds of attempts span over multiple connections, with each connection containing the same, small number of attempts. The characteristic flat behavior is used by many Intrusion Detection Systems (IDSes), both for identifying the presence of attacks and — once detected — for observing deviations, pointing out potential compromises, for example. However, flatness of network traffic may become indistinct when TCP retransmissions and control information come into play. These TCP phenomena affect not only intrusion detection, but also other forms of network traffic analysis. The contribution of this work is twofold. First, we analyze the impact of retransmissions and control information on network traffic based on traffic measurements. To do so, we have developed a flow exporter extension that was deployed in both a campus and a backbone network. Second, we show that intrusion detection results improve dramatically by up to 16 percentage points once IDSes are able to ‘flatten’ network traffic again, which we have validated by means of analyzing log files of almost 60 hosts over a period of one month

Towards real-time intrusion detection for NetFlow and IPFIX

DDoS attacks bring serious economic and technical damage to networks and enterprises. Timely detection and mitigation are therefore of great importance. However, when flow monitoring systems are used for intrusion detection, as it is often the case in campus, enterprise and backbone networks, timely data analysis is constrained by the architecture of NetFlow and IPFIX. In their current architecture, the analysis is performed after certain timeouts, which generally delays the intrusion detection for several minutes. This paper presents a functional extension for both NetFlow and IPFIX flow exporters, to allow for timely intrusion detection and mitigation of large flooding attacks. The contribution of this paper is threefold. First, we integrate a lightweight intrusion detection module into a flow exporter, which moves detection closer to the traffic observation point. Second, our approach mitigates attacks in near real-time by instructing firewalls to filter malicious traffic. Third, we filter flow data of malicious traffic to prevent flow collectors from overload. We validate our approach by means of a prototype that has been deployed on a backbone link of the Czech national research and education network CESNET

SSH compromise detection using NetFlow/IPFIX

Dictionary attacks against SSH daemons are a common type of brute-force attack, in which attackers perform authentication attempts on a remote machine. By now, we are used to observing a steady number of SSH dictionary attacks in our networks every day; however, these attacks should not be underestimated. Once compromised, machines can cause serious damage by joining botnets, distributing illegal content, or participating in DDoS attacks. The threat of SSH attacks was recently stressed again by the Ponemon 2014 SSH Security Vulnerability Report, which states that 51% of the surveyed companies have been compromised via SSH in the last 24 months. Even more attacks should be expected in the future; several renowned organizations, such as OpenBL and DShield, report a tripled number of SSH attacks between August 2013 and April 2014. After April 2014, the number of hosts blacklisted by OpenBL for SSH abuse continued to grow and peaks at all-time high values. These numbers emphasize the need for a scalable solution that tells security teams exactly which systems have been compromised and should therefore be taken care of. This is where our open-source IDS SSHCure comes into play. SSHCure is a flow-based Intrusion Detection System (IDS) and the first network-based IDS that is able to detect whether an attack has resulted in a compromise. By analyzing the aggregated network data received from edge routers, it analyzes the SSH behavior of all hosts in a network. Successful deployments—in networks ranging from Web hosting companies and campus networks up to nation-wide backbone networks—have shown that SSHCure is capable of analyzing SSH traffic in real-time and can therefore be deployed in any network with flow export enabled. The latest version of SSHCure features a completely overhauled compromise detection algorithm. The algorithm has been validated using almost 100 servers, workstations and honeypots, featuring an accuracy close to 100%

Real-time DDoS attack detection for Cisco IOS using NetFlow

Flow-based DDoS attack detection is typically performed by analysis applications that are installed on or close to a flow collector. Although this approach allows for easy deployment, it makes detection far from real-time and susceptible to DDoS attacks for the following reasons. First, the fact that the flow export process is timeout-based and that flow collectors typically provide data to analysis applications in chunks, can result in detection delays in the order of several minutes. Second, by the nature of flow export, attack traffic may be amplified by the flow export process if the original packets are small enough and are part of small flows. We have shown in a previous work how to perform DDoS attack detection on a flow exporter instead of a flow collector, i.e., close to the data source and in a real-time fashion, which however required access to a fully-extendible flow monitoring infrastructure. In this work, we investigate whether it is possible to operate the same detection system on a widely deployed networking platform: Cisco IOS. Since our ultimate goal is to identify besides the presence of an attack also attackers and targets, we rely on NetFlow. In this context, we present our DDoS attack detection prototype that has shown to generate a constant load on the underlying platform — even under attacks — underlining that DDoS attack detection can be performed on a Cisco Catalyst 6500 in production networks, if enough spare capacity is available

A first look at HTTP(S) intrusion detection using NetFlow/IPFIX

Brute-force attacks against Web site are a common area of concern, both for Web site owners and hosters. This is mainly due to the impact of potential compromises resulting therefrom, and the increased load on the underlying infrastructure. The latter may even result in a Denial-of-Service (DoS). Detecting brute-force attacks — and ultimately mitigating them — is therefore of great importance. In this paper, we take the first step in this direction, by presenting a network-based approach for detecting HTTP(S) dictionary attacks using NetFlow/IPFIX. We have developed a prototype Intrusion Detection System (IDS), released as open-source software, by means of which we can achieve accuracies close to 100%

Flow Monitoring Explained: From Packet Capture to Data Analysis With NetFlow and IPFIX

Flow monitoring has become a prevalent method for monitoring traffic in high-speed networks. By focusing on the analysis of flows, rather than individual packets, it is often said to be more scalable than traditional packet-based traffic analysis. Flow monitoring embraces the complete chain of packet observation, flow export using protocols such as NetFlow and IPFIX, data collection, and data analysis. In contrast to what is often assumed, all stages of flow monitoring are closely intertwined. Each of these stages therefore has to be thoroughly understood, before being able to perform sound flow measurements. Otherwise, flow data artifacts and data loss can be the consequence, potentially without being observed. This paper is the first of its kind to provide an integrated tutorial on all stages of a flow monitoring setup. As shown throughout this paper, flow monitoring has evolved from the early 1990s into a powerful tool, and additional functionality will certainly be added in the future. We show, for example, how the previously opposing approaches of deep packet inspection and flow monitoring have been united into novel monitoring approaches

Extending IP Flow-Based Network Monitoring with Location Information

Internet Draft - IETFIP Flow-based monitoring lacks a mechanism to associate measured IP Flow information with the geographic location of the device where theIP Flows have been observed. This document defines a set of guidelines and best practices to extend IP Flow monitoring protocols with location information of the device (both fixed and mobile) that acts as an IP Flow metering process